Notes/Domino Fix List
 |  |
| SPR # CBOE4TRKKK | Fixed in 5.0.8 release |  |
Product Area: Server Technical Area: Server - Database 5.0 - Logging & Recovery Platform: Win NT
SPR# CBOE4TRKKK - Fixed a problem where a database became corrupt when restore transaction log entries against a database that was over it's quota.
Technote Number: 1095469
Problem:
This issue was reported to Quality Engineering and has been addressed in Domino
5.0.8.
Excerpt from the Lotus Notes and Domino Release 5.0.8 MR fix list (available at
http://www.notes.net):
Server - Database 5.0 - Logging & Recovery
SPR# CBOE4TRKKK - Fixed a problem where a database became corrupt when restore
transaction log entries against a database that was over it's quota.
If the option "Obey database quotas during message delivery" is Enabled in the
Configuration document in the Domino Directory, the database can be recovered
from backup up to the size of the database quota. Once the quota has been
reached, however, any replayed transactions from the transactional log extents
cannot be applied to the database past the limit of the quota. This results in
lost transactions and lost data. Furthermore, the database quota cannot be
increased until the database is fully restored. Since transactions cannot be
applied over the database quota, a full database restoration is never achieved.
If "Obey database quotas during message delivery" is Disabled, a database quota
has been exceeded and the database must be recovered for any reason, during
recovery the transaction(s) would be replayed into the database (for example,
router delivering mail), so the database would be restored to its original
state (which is over quota).
To work around the issue, the database must be brought under quota and then
compacted to reduce the size of the database. When the problem occurs,
however, the default compaction style changes from copy style to in-place
compaction (with no file reduction) for any databases that are transactionally
logged. If users delete documents to bring the database under quota and
compact it, the database will still remain over quota since in-place compaction
is being used and the file size is not being reduced. The Administrator must
then compact the database using copy style compaction. When this is done,
however, it changes the DBIID. As a result, a full backup must then be taken.
Supporting Information:
Restoring transaction log file S0000445.TXN to
C:\NOTES\DATOS\LOGTRANS\S0000445.TXN
...
Restore of S0000445.TXN completed successfully.
...
Restoring transaction log file S0000446.TXN to
C:\NOTES\DATOS\LOGTRANS\S0000446.TXN.dad
...
Restore of S0000446.TXN completed successfully.
...
Restoring transaction log file S0000470.TXN to
C:\NOTES\DATOS\LOGTRANS\S0000470.TXN.dad
...dd/yy/yyyy 10:41:10 No es posible asignar el objeto de la base de datos
C:\NOTES\DATOS\mail\dciguel.nsf.dad; sta superara su cuota de espacio en disco
(133120 kB) en 12058624 bytes.
**** DbMarkCorrupt(Error detected during Undo/Redo.),
DB=C:\NOTES\DATOS\mail\dciguel.nsf.dad TID=[002F:0002-00ED] ***
(In English):
'It's not possible to assign the database object
C:\NOTES\DATOS\mail\dciguel.nsf.dad; This exceeds the quota of space disk
(133120 kB) in 12058624 bytes. More >
Last Modified on 06/06/2001
Go back
|